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FI ELD AI^D BACKGROUND 

The present invention is of a mstliod and a system for the management of 
comniuiittiation ses^;ions for computer network-based telephone communication, and in 
15 particular for the identification of packets containing audio and/or video data, for the 
storage of these packets, and for the reconstruction of selected communication sessions 
for audio caid/or video display as needed. 

Tlr: iniegration of the computer into office communication systems has enabled 
many functions previously perfonned by separate devices to be combined into a single 
20 management system operated through a computer. For example, computer-based voice 
logging systems enable a computer to receive voice conmiunication through a hardware 
connection to the regular telephony nemork, to record either a conversation, in which at 
least two p'Orties converse, or a message from at least one party to one or more parties, 
ajid to replay these njcorded conversations or messages upon request, 'i^hese voice 
25 logging systems can replace mechanical telephone answering machines. 

Thf^ computer logging systems have many advantages over the mechanical 
LHnswering machines. For example, the voice messages can be stored in a computcr- 
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based storage medium, such as a DAT cassette, wliich has a greater storage capacity 
than regulir audio cassettes, FurUiermore, the stored voice messages can be organized 
in a database, such lhat the messages can retrieved according to time, date, channel, 
dialed nuribcr or caller identification, for example. Snch organisation is not possible 

5 with a meL-ihanical telephone answering machine. Thus, computer logging systems for 
voice mcsaagss hsive many advantages over mechanical aiiswenng machines, 

UriCominately, currently available computer logging systems have the 
disadvantage of being unable to record telephone communication sessions, whether 
con vernations or messages; for voice communication being perfomied througli a LAN 

10 (local areii network) or a WAN (wide area network). Although these logging systems 
can play back voice messages to a remote itser through a LAN, tor example, they 
cannot retOTd such a message ii' it is transmitted by a LAN-based telephone. Such LAN 
and WAN based telephone communication has become more popular recently, since it 
enables telephone communicQTion to be performed between various parties at physically 

15 separated sites without paying for local regdar telephony network services, thereby 
saving money. 

Furthermore, LAN and WAN based telephone comm\mication also facilitates 
rhe transmission of video as well as audio information. Video information certainly 
cannot be recorded by currently available computer logging systems. Thus, the inability 
20 of computer logging systems to record telephone communication sessions for telephone 
communication being perfoiined through a LAN or a WAN» including both video and 
audio data, is a significant disadvantage of these systcms- 

Ti jere is therefore a need for, and it would be highly advantageous to have, a 
system and a method for recording telephone communication sessions performed over a 
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computer network, such as a LAN or a WAN, which would recoi-d both audio and video 
infoii nation, organize such information, and then display such informauon upon 
request. 

TIic switching industry is moving towards tlie IP world. This move is having a 
huge impuct on the telecoininunications industry. It is too early to uivJersiand the full 
impact of this move. 

The IP multimedia initiative got Us momentum when the International 
Telecommunications Union published the H.323 standard ensuring compatibility 
between switching product.s from different vendors. The H.323 standard provides a 
10 foundation for audio, video and data commimication across IP-based networks 
including iJie Internet. 

Mcst of the main switching vendors such as Lucent, Siemens, Nortel and 
Alcatel have decided to integrate IP into their current switching platfonns- Vciy soon, 
tliesc vendors will present the market with new switch platforms based on IP 
IS technology. 

All current recording solutions are based on the fact that a PBX or a central 
office utilize.? a central switching matrix, with all calls being routed via this central 
matrix. Iniegration with this matrix insures that all calls routed by the PBX or central 
office could be recorded by a digital recording system tlmt has a connection to the 
20 switch matrix. This, however, is inconsistent with Uie IP environment, which is 
inherently clecentralized. 

TTicne is therefore a need for, and it would be highly advantageous to have, a 
system nnd a method for recording telephone commujii cation sessions perfomed over a 
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-k, such as a LAN or a WAN, that would be iridepeadeni of a central 



computer nctv, orl 
sv^tchiDg matrix. 



c. iMK^A P V OF fHE INVENTION 
5 It is one object of the present invention to provide a system aad a method for 

recording communication sessions performed over a compater network. 

li is enoTher object of the present invention to provide such a .system and method 
for analyzing data uansmitted over tlie computer network in order to detect audio and 
video dat£i for recording. 
10 It is still anotlier object of the present invention to provide such a system and 

method for displaying nworded video and audio data upon request. 

It is yet another object of the present invention to provide such a system and 
method Jor analyzing, recording and displaving communication sessions conducted 
with aL/^N-based telephone system. 
,5 These and other objects of the present invention are explained in farther detail 

with ragixi to die drawings, description and claims provided below. 

The present invention provides a system and a method for analyzing data 
packets on a computer netv,'ork, for selectively recording atjdio and video data packets, 
for orgjuiizing this stored information and for displaying the stored information upon 
20 request, such that communication sessions with computer network-based "telephone ' 
systems can be logged. 

According to the teachings of the present invenlioa, there is provided a system 
for managing a communication session over a computer network, the system 
comprising: (a) a network connector for comiecUng to Ihs computer network and for 
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receiving date packets from Uie computer network; 0) a filtering unit for filtering the 
data packets and for accepting the data packets substantially only if the data padcets 
contain data selected from Uie group consisting of audio data and video data, such that 
the data ]5ackcts form at least a portion of the communication session and snth that the 

s data packets are selected data packets; (c) a management unit for receiving the selected 
data packets and for storing the selected data packets, such tliat the selected data 
packets ^.re stored data packets; and (d) a storage medium for receiving and for storing 
the stored data packets from the management uniL» such that the at leaut a portion of the 
communication session is stored. 

10 Preferably, the system fiiitlTer comprises (e) a data restore unit for retrieving aiid 

displaying the at least a portion of the communication session, the data restore unit 
rcquesLing the data packets from the storage medium llirough the management unitj and 
the data, restore unit reconstnicting the data packets for displaying the at least a portion 
of the cominOTtcation session. 

15 More preferably, the data restore unit Purlher comprises a communication 

session displHy unit tor displaying the at least a portion of tlie communication session. 
Most preferably, the comrounication session display unit is selected from the group 
consisting of a video unit and an audio unit. 

i^^ccofding to preferred embodiments of the present invention, the system further 

20 comprisiis (1) a database connected to the flheiing unit for storing filtering information, 
the filtering infonnation including at least oue TP address of a party whose 
communication sessions are monitored; wherein the filtering unit accepts the data 
packets according to the filtering information, such that the filtering unit substantially 
only accepts the data packets if the data packets fulfill the filtering information. 
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Pr^ibrably. the system ftirther comprises (g) a user computer far receiving at 
least one canunand of a user and for displaymg infonnatiou to the user, such that the 
user determines the filtering iT,foni,alion according to the at least one comm^.nd of the 

user. 

5 More preferably, the computer netwoit is selected from tl^ group consisting of 

a (local area network) and a WAN (wide area network). Most preferably, ihe 
compute! TietN\'ork is a kAN (local area network). 

According to further prefeixed embodiments of the present invention, the LAH 
is divided into at least tv/o segments, the system fiirther comprising: (h) a local 

,0 tna.agen.ent u.it for each segment, the local management unit including the filtering 
utut ^d the management uniU mi (i) a central management unit for controlling the 
local managenieut units, the central nianagement unit conlroUing storage in the storage 
mediuw 

I'referably, the network connector is a network interface card. 
According to another embodiment of the present invention, there is provided a 
method for Storing at least a portion of a commnnicalion session performed on a 
computer network, tl^e commuiiication session bemg perfom^ed beuveen a packet 
source and a packet destination, the steps of the method being perforoied by a data 
processor, the method comprising the steps of: (a) receiving a data packet &om the 
20 packet souice on the computer ncnvork; (b) analyzing the data packet to determine if 
Ihc dat;i packet is an IP packet; (c) If the data packet is the IP packet, filtering the IP 
packet to detemiine a type of the IP packet; and (d) storing lite IP packet to form a 
stored .data packet according to the type, such that the stored data packet fomns at least a 
portiorL of the communication session. Preferably, the step of analyzing the data packet 



15 



09 OIJ 12:35 ©fl72 3 3025534 



DR. M. FRIEDMAN 

# 



®014 



7 

is performed by examimng a header of the data packet. 

According to a preferred embodiment of the present invention, the st£p of 
filtering liie IP packet is perfonned by examining the header of the IP packet. 

Preferably, the step of fiUermg the TP packet farther comprises the steps of: (i) 
5 exaaiiijiin;; the header of the IP packet to detemaine an IP address of the packet source; 
(ii) detemiining if the IP address is a recorded IP address: (iii) passing the IP packet to 
form a passed TP packet substantially only if the IP address is the recorded TP address; 
and (iv) dternativeiy, dmiping the IP packeL 

More preferably, the step of determining if the IP address is the recoided IP 
10 address is perfbrrried by comparing ilie JP address to a list of IP addresses from packet 
sources, such that if tlie IP address is included in the list, the IP address is the recorded 
TP address. 

Also preferably, the step of filtering the TP packet further comprises the steps of; 
(v) detemiining whetlier tlie passed IP packet is an H.225 packet, a H.245 packet, an 

15 RTP packet or an RTCP packet; (vi) if the type of the passed IP packet is the H.225 
packet, determimng whether the H.225 packet is a setup packet or a comieci packet; 
(vii) if the H.225 packet is the setup packet, setting a status flag as "iitart session 
request"; (\'iii) alteujatively, if the H.225 packet is the connect packet and the stams 
flag is ''start sessioii request", storing at least one detail of the communication session; 

20 and (ix) seining the status flag as ''wait for logic cliannel". 

More preferably, tlie step of rdtering die CP packet ftiitlier comprises the steps 
of: (X) alternatively, if the type of Uie passed IP packet is the H.245 packet, determining 
whether the H.245 packet is an open logical chaiuiel request packet, an open logical 
channel ac:<nowledgment packet or a terminal capability set packet; (xi) if the H.245 
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packei: is i he open logical channel request packet and the status flag is "Avail Ibr logic 
ciianiier\ setting the status flag as "wait for acknowledgment"; (xii) alternatively, if the 
H.245 packet is tlic open logical cliaancl acknowledgment packet and the status flag is 
''wait for acknowledgnaent'', performing the steps of: (A) setting the status Hag as ""wait 
5 for terminal capability''; and (B) sa\ing a transport address of the destination of the 
communication session; and (xiii) also alternatively, if the H.245 packet is the teiminal 
capahility set packei, performing the sieps of; (A) storing a capability of llie packet 
destinatiotL from the terminal capabih'ty packet; and (B) setting the statiifj flag as ''in call 
process". 

10 Mcrst preferdbly, if the status flag is "in call process" and xhe type of the passed 

IP packet is the PJP packei, the RTP packet is stored. Also most preferably, if the 

status flag is Hi\ call process'* and the type of the passed IP packet is the RTCP packet, 

the RTCP packet is stored. 

According to another preferred embodiment of the present invention, the 
!5 method Ikther comprises the steps of: (e) retrieving the stored data packet to form a 

retrieved data packet; and (f) reconstructing at least a portion of the conunimication 

session according to the retrieved data packet. 

Preferably, the step of retrieving the data packet includes the steps of; (1) 

receiving e source IP address of the packet source, a start time of tlie communication 
20 session, and an ead time of the communication session; and (ii) selectiiig at leasi one 

communication session accordijig to the source IP address, the start time and the end 

time. 

Also prafeiably, the step of reconstmcting at least a portion of the 
communication session includes displaying audio data. 
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-Alternatively and also preferably, the step of reconstructing at least a portion of 
the cojiLmunication session includes displaying video data. 

More preferably, the step of reconstnjctiiig at least a portion of the 
coimnunication session fcrther comprises the steps of: (i) retrieving substantially only 
5 RTF packets; (ii) exan-iining a header of the RTF packets to detemiine a time stamp for 
each of the RTF packets; aiid (iii) displaying the RTF packets in an order according to 
tlie time stamp. 

According to the teachings of the present invention, there is provided a system 
for mana|!:ing a communication session over a computer nenvork that includes a 
;Q 10 gatekeeper, the system comprising: (a) a network connector for connecting to the 

ill computer netwoik and for receiving data packets fi'om the computer network; (b) a 

'r:^ fdtering unit for filtering the data packets and for accepting the data packets 

i n substantia ly only if tlie data packets contain data selected from the group consisting of 

audio daiii and video data, such that the data packets form at least a portion of the 
{2 15 conamunication session and such that the data packets are selected data packets; (c) a 

nianagem<:nt unit for receiving the selected data packets and for storing the selected 
data packets, such that the selected data packets are stored data packets; (d) a storage 
medioni for receiving and for storing the .stored data packets from the management unit, 
such that ':he at least a portion of the communication session is stored; and (e) a link, 
20 between die gatekeeper and the management unit, for transferring information related to 
the data packets from the gatekeeper to the management unit. 

Preferably, the system farther comprises (f) a data re.store unit for retrieving and 
displaying the at least a portion of the communication session, the data restore unit 
requesting the data packets ftom the storage medium through the management unit, and 
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the data resiore ujiit reconstructing the data packets for displaying the at Icasi a portion 

of the coiHiiiunication session. 

More prefembly, tlie data restore unit further coinprises a communication 

session display unit for displaying the at least a portion of the conifiiunication session, 
s Most preff;ral)ly, the communication session display unit is selected from the group 

consisting of a video vmit and sin audio unil. 

According to preterred embodunents of the present invention, the system further 

comprises (g) a database connected to the filtering unit for storing filtering informatioru 

the filtering infomiation including at least one TP address of a party v.*ose 
i 10 conimuaication sessions are monitored; wherein the filtering unil accepts Ihe data 

fl paclscts accordmg to the filtering infonnation, such that the fiUering unit substantially 

U only accepts the data packets if the data packets fulfill the filtering information, 

f j Prefeiiibly. the system further comprises (h) a user computer for receiving at 

least one command of a user aiid for displayij^g information to the user, such tliat the 
^ 1 5 user deiermines the filtering information according to the at lea.?t one command of the 

3 Mtjre preferably, the computer network is selected fiom tlie group consisting of 

a LAN (local area network) and a WAN (wide area network). Most preferably, the 
computer network is a LAN (local area network). 
20 According to fiirther preferre4 embodiments of the present invention, the LAN 

is divided inlo at least two segments, the system jEurtlter comprising: (i) a local 
managcrDcnt unit for each segment, the local management unit including the filtering 
unit and the management uniu and Q) a central management unit for coiitroUing the 
local managcmeni units, the central management unit controlling storage in the storage 
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mediiLm. 

P] eferably^ the network coimectoi is a network interface card. 

According to another embodiment of the present invention, there is provided a 
method ibr conducting a communication session on a computer network between a 
5 packet source and i packet destination, comprising the slep.^ of: (a) setting up the 
communication session according to a first protocol suite; and (b) storing at least a 
portion of the conimunicatioii session according to a second protocol suite different 
from the first protocol suite, the storing being performed by a data processor. For 
example, Ihe second protocol suite may be an IP protocol suite, 

q 

i y 10 Preferably, ihe storing of the portion of the communication session is performed 

III by steps including: (i) receiving a data packet from the packet source on the computer 

network; (ii) analyzing the data packet to determine if the data packet is in accordance 
in with the !;econd protocol suite; and (iii) storing the data packet to form a stored data 

packet, such that the stored data packet forms at least a portion of the communication 
{2 session. Preferably, the step of analyzing the data packet is effected by examining a 

. 5 header of the data packet. 

According to another preferred embodiment of the present invention, the step of 

storing the at least a portion of the communication session further comprises the step 

of: (iv) sv.bsequent to the analyzing, if the data paclcet is in accordance with the xecond 
20 protocol suite, filtering the data packet to determine a type of the data packet. 

Pieferabl) , the step of analyzing the data packet is performed by examining a header of 

the dnta packet, and the step of filtering the data packet is peiformed by examining die 

header of the data packet. 

Pniferably, the second protocol suite is an IP protocol suite, the data packet is an 
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JP pack(jt, and the step of filtering tlie IP packet furtlier comprises the steps of: (i) 
examin ing the header of the JP packet to dctenmine an iP address of the packet source; 
Cli) detdmining if the IP address is a recorded IP address; (iii) passing the IP packet to 
form a p^tssed IP packet substantially only if the IP address is the recorded IP address; 
5 and (iv) i^lteniatively, dumping the IP packet. 

More prefembiy, the step of deteTmining if the IP address is the recorded IP 
addresK is performed by comparing the IP address to a list of IP addresses from packet 
sources, such that if the IP address is included in the list, the IP address is the recorded 
IP address. 

10 Most preferably, if the passed IP packet is an RTP packet, the RTP packet is 

stored. Also most preferably, if the passed IP packet is an RTCP packet, the RTCP 
packet is stored. 

P:referably, the storing of the data packet is eflFected according to the type of the 
data packet 

1- According to another preferred embodiment of the prcseat invention, the step of 

stivring iht at least a portion of the canununication session further comprises the steps 
of: (iv) retrieving the stored data packet to form a retrieved data packet; and (v) 
reconstructing at least a portion of the communication session according to the retrieved 
data packet. 

20 Preferably, the second protocol suite is an IP protocol suite, and the step of 

retrieving the data packet Includes the steps of: (A) receiving a source IP address of the 
packet source, a start time of tlie commimication session, and an end lime of the 
commuinioation session; and (B) selecting at least one communication session according 
to the source IP address, the stan time and the end time. 
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.^aso preferably, ihe step of reconstructing at least a portion of the 
coaununication session includes displaying audio data. 

Alternati vely and also preferably, the step of Kfconstrucling gt least a portiou of 
the conuiiunication session includes displaying video data. 

More preferably, tJie step of reconstructing ai least a portion of the 
comaiunicauon session fiirther comprises the steps of: (A) retrieving substantially only 
RTP packets; (B) examimng a header of ihe RTP packets to determine a time stamp for 
each of tiie RTP packets; and (C) displaying the RTP packets in an order according to 
tlie time stamp. 

Hc:reinafter the term "cominunication session" includes both a conversation, in 
which at least two parties converse by exchanging audio aad/or video information in 
•Veal time", and a message, in which at leait one party records such audio and/or video 
iuformaticji for reception by at least one other party at a later date. 

Hcreinatter, die term "Inteniet" is used to generally designate the global, linked 
15 web of thousands of networks which is used to connect computers all over the world. 
As used herein, the term "intranet" mcludes other types of computer networks, such as 
LAN (local area neKvorks) or WAN (wide area networks). The term "computer 
network" includes any connection betweeji at least uvo computers which permits the 
tiMsmission of data, including both hitemet and intranet. The tcm "regular telephony 
20 network" includes POTS (plain old telephone system) and substantially any other type 
of telephone network which provides services through a regular telephone services 
provider, but whicli specifically excludes audio and/or video communication performed 
tlirough any type of computer network. 
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I:[ereinafter, the tenn "computer" includes, but is not limited lo, personal 
compulers (PC) having an operating system such as DOS, WindowaTw, 05/2^" oi 
Linux; MacJciniosh^^^ computers; computers having JAVA'^-OS as the operating 
system; ^md graphical workstations such as the coniputers of Sun Microsystems ''^ and 
5 Silicon Crraphici-^M^ ^^^er computers having some veniion of the UNIX operating 
system snch as AIX or SOLARIS-^ of Sun Microsystems^^; or any other knovvn and 
available operating system. Hereinaller, the tenn "Windows^w*^ includes but is not 
limited to Windows95^, Windows 3.xtm in which "x'' is an integer such as "1", 
Windows N'F^, WindowsgS^^*, Windows CE''^ and any upgraded versions of these 
10 operating systems by Microsoil Inc. (Seattle, Wa^shington, USA). 

Hereinafter, Uie term "logging'* refers to the process of analyzing data packets 
on a nelvv'ork to locate audio and/or video data, and of recording .5uch data m an 
organized system. Hereinafter, the term "display" includes both the visual display of 
video dat£, and the production of sound for audio data. 

]? 

BRIEEJ3 ESCR1PTI0N OF TUF. DRAWINGS 

Th- invention is henein described, by way of example only, with rclerence to the 
accompan^rdng drawings, wherein: 

FIC5. 1 is a schematic block diagram of an exemplary conununication session 
20 monitoring; system according to the p^scnl invention; 

FICf. 2 is a schematic block diagram of tlie software modules required for 
operating trie system of Figure 1, 

FIGS. 3A-3D are flowcharts of exemplary filtering and recording methods 
according to the present invention; 
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F(GS. 4A-4D ans schematic block diagrams shoudng Ihe headers of ti.225 
(Fig^ AAl H.245 (figure 4B), RTP (Figure 4C) and RTCP (Figure 4D) packets, as 
they relate to the present invention; 

FIG. 5 is a Hovvchart of an exemplary comcnunication session playback method 
5 according to the present invenu'ou; 

FIG. 6 is a sclicmatic block diagiam of an exemplary first embodimem of a 
basic systftTi using the communication session monitoring system of Figures 1 and 2 
according to the present invention; and 

FIG. 7 is a sciiemiitic block diagram of en exemplary second embodimem of a 
1 0 zone syslem according to tlie present invention; 

FI(3. 8 is a schematic block diagram of an exemplary passi ve lecordine system 
according to another embodiment of the present invention. 

DESCKIP'QQ N OF BACKGROI JNn ART 

15 Th*: Ibllowing description is intended to provide a description of certain 

!.<ackground methods and technologies which are oprionally used in the method and 
system of the present invention. The present invention is specifically not drawn to 
these meth.:.ds and technologies alone. Rather, they are used as tools to accomplish the 
goal of the: present invention, which is a system and a method for analyzing data 

20 packets on a computer network, for selectively recording audio and video data packets, 
for orgaiiiziing this stored information and for displaying the stored infotruation upon 
request, suc;li that communication sessions with computer network-based "telephone" 
systems can be logged. 
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rhc system and method of the present invention is particularly intended for 
opeialiou ^vith computer networks coiistmcied according to che iTli^T 
Reconnnendatiou H.323 for visual telephone systems and equipment for loc.^ area 
network, which provide a noa-guaraateed quaUty of service. Recommendation H.323 
5 is herein inconx>rated by reference in order to further describe the hardware 
requa™ts and operating protocols for such computer networks, and is hereinafter 
refeired to as '-'11.323". 

H.323 describes terrninaJs, equipn^ent and services for muhimedia 
communication over Local Area Networks (LAN) which do not provide a guaranteed 
10 quality of service. Computer terminals and eqidpAient Avhich fulfill H.323 may cany 
real-tune voice, data and video, or any combination, including videotelephony. 

The LAN over which such terminals communicate can be a single segment or 
rin. or optionally can include muhiplc segments with complex topologies. These 
tenninals ,.e optionally integrated into computers or alternatively are implemented in 
15 stand-alon. devices .uch as videotelephones. Support for voice data is inquired, while 
support fox general data and video data ar* optional, but if supported, the ability to use a 
specified common mode of operation is required, so that all terminals supporting that 
particular media type can communicate. The H.323 Reco.nmendalion aUows more than 
one channel of each type to be in use. Other Recommendations in the H.323^Series 
^0 which are also incorporated by reference include H.225.0 packet and synchromzation, 
H.245 control, H.261 ar.d H.263 video codecs, G.711. G.722, G.728. G.729, and 0.723 
audio codecs, and the T. 120.Serie3 of multmiedia communications protocols. 

ITU-T Recommendation H.245.0 covers the defmition of Media stream 
packetization and synchronization for visual telephone systems. ITU-T 
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Recomm^indation H.245.0 defines tlie Control protocol for multimedia 
communications, and is hereinafter reigned to as "H.245". H.245 is Incorporated by 
fefereucc as is fully set forth herein. 

Tlie logical chaionel si^^aling procedures of H.245 describes tlie content of eacli 
5 logical chamicl when the channel is opened. Procedures arc provided for the 
C0T7imuni 'Million of the Functional capabilities of receivers and transmitters, so that 
transmissions arc limited to infomiation which can be decoded by the receivers, and so 
that receivers may requcsi a paiticuk^r desired mode from transinittcrs, 

H.245 signaling is established between two endpoints; an cndpoint and a multi- 
ivO point conlToUer, or an endpoint and a Gatekeeper. ^Die endpoint establishes exactly one 
H.245 CoDtiol Chajinel for each call that the endpoint is paiticipating in. The channel 
must then operate according to H-245. Support for multiple calls and hence for multiple 
11.245 Control Channels is possible. 

The RAS signaling function uses H.225.0 messages to perform registration, 
15 admissions, bandwidth changes, status, and di^sengage procedures between endpoints 
and Gatcl.eepers. In LAN environments that do not have a Gatekeeper, the RAS 
Signaling Channel is not used. In LAN environments which contain a Gatekeeper, such 
that the L/\N includes at lea$t one Zone, the RAS Signaling ChLuinel is opened between 
the endpoint and the Gatekeeper. The RAS Signaling ChanneJ is opened prior to the 
20 establi&lunent of any other channels betwcn H.323 endpoints. 

Tht; call signaling fimction uses H.225.0 call signaling to estabUsh a connection 
between r\vo H.32j endpoints. The Call Signaling Channel is independent from the 
RAS ChGLncl and the H.245 Control Channel. The Call Signaling Channel is opened 
prior to tlu establisliment of the H.245 Channel and any other logical channels between 
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H.323 endpoinii. In systems thai do not hal! a Gatekeeper, the Call Signalme Chaiuiel 
is openc^d betv;een the two endpoints mvolvcd .„ call. In systcins which contain a 
Gatekeeper, the C^l Signaling Channel is opened between the end point and the 

Gatekeeper, or between the eiidpoints themselves as chosen by the Gatekeeper. 

CotTCSponding to the various channels defined by H.323 are corresponding 

protocol, that collectively constitute the H.323 protocol suite. These protocols include 

the H.225 and H.245 protocols for session setup and the RTP and RTCP protocols for 

die aciu^il d£tta exchange. 



DESC^jZTLON OF TIlE PRRFFRRFH rMBODTMRNTS 

Tiic present invention provides a system and a method for analysing data 
packets on a computer network, for selectively recording audio and video data packets, 
for oiganizing this stored information and for displaying the stored infonnatioii upon 
truest, s^ch that communication sessions ^vith computer network-based -telephone" 
sy.stems cjin be logged. 

The principles and operation of a method and a system according to the present 
invention may be better understood with reference to the drawings and the 
accompanying description. 

Reierring now to the drawings, figure 1 is a block diag.^ of an exemplary 
system for logging and displaying audio and/or visual data from communication 
sessions performed over a computer network. A computer logging system 10 features a 
user computer 12 connected to a commmiication session management unit 13. 
Communicution session manafienient unit 13 is in tum connected to an intranet 14 
through d network interface card (NIC) 16. 
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User computer 12 inciud« a user interface 18. which is preferably a GUI 
(s-phical user i.,terface)„ whicli is din>layed on a display unit 20. User interface 18 
preferably enables the i^er to enter such intbnnalion as the definilion of the paxtle. 
whose calls should to be monitored andyor logged, and which also prelfen,bly enables 
5 the user to enter at least o,. comn,and for retrieving and displaying a communication 



session. 



Display urut 2U is preferably a con,puter xnonitor. The user is able to interact 
witJn user coniputer 12 by entering data aitd commands through a data entiy device 22. 
Data ..try device 22 pre/erably includes at least a keyboard or a pointing device such as 
•0 a mouse, and more preferably includes both n keyboaid ^d a F«>inting device. 
According to one preferred embodiment of the present invention, user computer 12 is a 
PC (perscnaJ computer). Alternatively and preferably, user computer 12 is a "thin 
client'' suc:h a net computer which is a computer able to communicate on an IP-bascd 
net^v-ork. One exampk of such a net computer is the JavaStation^^ (Sun Mic«)systems). 
15 The advan tage of such net computers ... that they allow the user to interact with 
complex, sophisticated software prog,^m.s, yet generally do not have ail of the powerful 
computing capabilities of currently available PC computers. 

Intr.net 14 could be a LAN or a WAN, for example. The co.mection between 
communication session ma^mgement unit 13 and intranet 14 occurs through NIC 16. 
-^0 NIC 16 is preferably any standard, off-the-shelf commercial product which enables 
communication session management unit 13 to be connected to any suitable computer 
network (for example, Etherlink U ISA/PCMCIA Adapter or Ethetiink m PCI Bus- 
Master Adapter (3C590) of 3-Com-, or NE20OO Adapter of Novell™ or any other such 
suitable prchtct). Examples of .uch suitable computer networks include, but are not 
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limited io. my standard LAN such a.s Ethernet (IEEE Standard 8023), Fast Ethernet 
(IEEE SUiiidard 802;10X Token Ring aEEE Standard 802.5) and FDDI. 

All data packet traffic on intranet 14 is passed to a filtermg module 24 through 
NIC 16. As shown in mors detail in Figure 3 below, filtering module 24 screens the 
5 data packets in order to determine which data packets fulfill the following criteria. 
Briefly, ibe data packets should be 1? packets with headers according to the H.225 and 
H-245 standards, indicating voice and/or video traffic. As noted previously, these 
standards define media stream packet construction and synchronization for visual 
telephone systems aiul the control protocol for multimedia communications. 
• O 10 Filtering module 24 then preferably passes substantially only those data packets 

jfi which meet these criteria to a management module 28. In the Zone Coniiguration of the 

system of the present invention, shown in Figure 7 below, fihering module 24 
i f! preferably also transfers messages fl*om other communication session management 

I ^. units. 

= 0 

1^' 15 Management module 28 receives the data packets passed through by filtering 

[z, I'.iodule 24, and analyzes the received data packets. Optionally and preferably, a 

=^ database 26 store-s such information as tlie TP addresses of parties v/hose 

eommimi cation sessions shouJd be logged^ as well as tlie conversion table associating 
each party with at least one IP address, foi example. The stored list of IP addresses 
20 representing tliose parties whose calls should be logged is preferably user-defined. As 
used herein, the term "party" refers to a person or persons communicating tlirough a 
computer network-based telephone system. The latter preferned lequLreroent 
significariUy reduces the amount of data stored by including only data which is of 
interest to the user. ?vlanagemsnt module 28 analyzes and manages data in accordance 
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with the £Lpplicable 11.225 luiri H.245 specifications, including ihe H.245 control 
ftjnction, PAS signaling function and call signaling ftinction, substaiilially as described 
above in the •'Description of the Backgroimd Art'^ section 

Management module 28 analyzes the packets in ordei to detennine the specific 

5 commiinicaticn session to u'lucii the data packets belong^ The tj'-pe of da!a compression 
being usieJ (if any), and whellier the data paxikets were sent from an IP address which 
should be nioiiitored. Management module 28 must perlbrm this analysis since 
filtering module 24 simply passes all data paclcets which fulfill the criteria described 
briefly above (see Figures 3A-3D for more detail). Since these packets are passed 

10 v;ithcKit rc imd to any of the information stored in database 26, management module 28 
must conijwe the nilcs of database 26 to the information present in the packet header 
of eacli packet in order to determine whether the received packet should be stored. 

ThLiSe lecdvcd packets which fulfill the rules of database 26 are t^ien stored in a 
storage medium 30, which is preferably a high capacity digital data storage device such 

15 as a hard disk magnetic storage device, an optical disk, a CD-ROM, a ZIP or DVD 
drive, or u DAT cassette, or a combination of such devices according to tlie operational 
needs of specific applications, or any other suitable storage media. Preferably, the 
specific conununication session or 'telephone cair\ with which each data packet is 
associated, is also stored in order for that session to be rcconstrucied and dispkiyed at a 

20 later time. 

Upon request by die user, management module 28 can then retrieve one or more 
data packets from storage medium 30 which are associated with one or more 
coniniunii:ation sessions. The retrieved packet or packets are then tnmsferred to a data 
lestoie module 32. Data restore module 32 is preferably capable of manipulating these 
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retrieved packets to restore a particular coiiununication session by using the RTP (Real 
Tijne ri-otocol). As described in fuither detail below with regard to Figw ts 4C and 5, 
in those systems which follow the RTP, the data packets are sent wth a time stamp In 
the header rather than just a sequence number. Such a time stamp is necessary for 
5 audio and video stream daia, in order for the data packets to be reassembled such Oiat 
the overall timing of the stream of data is maintained. Without such a time stamp, the 
proper tin)ing would not be maintained, and the audio or video streams could not be 
accurdtely reconstructed. 

The communication sessions are restored from the reconstructed streams of data 
i'-> packets b^r using the applicable audio and/or video CODEC'S. A CODEC is a non- 
linear method for the conversion of analog and digital data. Thus, an audio CODEC 
enables the. digitized audio data in relevant data packets to be converted to analog audio 
data loi display to the user as audible sounds, for example. Suitable CODEC'S are 
detoibed in gieatcr detail below with regard to Figure 5. 
15 In order for the user to receive the display of the reconstructed communication 

sef sion, system 10 preferably features an audio unit 34 and a video unit 36, collectively 
referred to as a "communication session di$play unit". More preferably, both audio 
unit 34 and video unit 36 are capable of both receiving audio or video input, 
respectively, and of displaying audio or video output. At die veiy least, audio unit 34 
20 and video unit 36 should be able to display audio or video output, respectively. For 
example, audio unit 34 could optionally include an microphone for input and a speaker 
or an earphone for output. Video unit 36 could optionally include a video monitor or 
di.9play scKcn for output and a video camera for input, for example. 
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Figare 2 is a schematic block diagram of syAlem 10 of Figure 1, showing the 
overall system of softwaitf modules of system 10 in more detail. Reference is also 
made, whtiie appiopriatc, to flow charts showing the operation of these software 
modules in more detail (Figures 3A-3D and Figure 5), as well as to descriptions of the 

5 headers of the dififerent types of data packets (Figures 4A-4D). 

As; shown, system 10 again includes a connection to intranet 14 through NIC 16. 
As the packets arc transmitted through intranet 14, NIC 16 intercepts these data packets 
cind passes them to filtering module 24. 

Filtering module 24 has two components. A first filtering component 38 

10 examines die header of the data packet, wtxich should be an IP type packet with the 
correct heiider, as shown in Figure 4A bdow. Next, first filtering component 38 passes 
xlie data packet to a second filtering component 40, Second filtering component 40 then 
determines the type of IP data packet, which could be constructed according to tlie 
H.225, 1-1.245, RTF or RTCP snmdards. 

15 As shown witli reference to Figure 3A, first filteriTig component 38 and second 

fihering ci^mponent 40 operate as tbllows. In step one, a packet is received by fiUering 
module 24. The packet is given to first filtering component 38, which then determines 
whether the packet is an IP type packet in step two. Such a determination is performed 
to the stTMCture of the header of the data packet, an example of which is shown in 

20 figure 4A. A header 42 is shown as a plurality of boxes, each of which represents a 
portion oi 'Tield" of die header. The number of bytes occupied by each portion is also 
shown, it being understood that each layer consists of 32 bits. The first portion of the 
header, a portion 44, is the protocol version number. Next, an "H. LEN^' 

portion 46 indicates the number of 32-bh quantities in the header. A "SERVICE 
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TYPE portion 48 indicates whether the seader prefers the datagrain to travel over a 
route vAxh minimal delay or a route with maximal throughput. A 'TOTAL LENGTH" 
portion fiO indicates the total number of octets in both Uie header and the data. 

lii the next layer, an 'TOENTTf JCATION" poitioa 52 identifies the packet itself. 
5 A "FLAGS" portion 54 indicates whether the datag^ is a fegment or a complete 
datag.^. A "FRAGMENT OFFSET" portion 56 specifies the locadon of t].is 
fragment in the original datagram, the datagnmi is fragmented. In the next layer, a 
-"nME TO LIVE" portion 58 contains a po.sitive integer between 1 and 255, which is 
proeressively decremented at each route traveled. When the value becon.cs 0.. the 
10 packet ^viIl no longer be passed and is rett.nicd to the sender. A "TYPE" portion 60 
mdicates the type of data being passed. A "HEADER CHECKSUM" portion 62 
enables the intefirity of the paclcet to be checked by comparing .he actual checksum to 
the value recorded iji portiou 62. 

Th. next layer of header 42 contains the source IP address 64, after which the 
15 Following layer contains the destination IP address 66. An optional IP OPTIONS 
portion 68 is present, after v.hich there is padding (if neces3ary) and a data portion 70 of 
tiie packet containing the data begins. 

The structure of tine header of the data packet is examined by first filtering 
coniponcnt 38 to determine wheUier this header has the necessary data fields In Ure 
20 correct order, such that the header of the data packet has a stmcture according to header 
42. First filtering component 38 only allows those packets ^v^tfa the correct header 
stn^ture to pass, a. shown in step 3A. Otherwise, the packets are dumped as shown in 
Step 3B. 
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Thc..^ packets ^vith the correct heL, or "'IP packets", are then passed to 
.eccd ftllerins component 40. Second fiiterit^ compoaent 40 thct. performs the 
,e«mind.r of th. filtering steps. In step 3 A. second Fdtering component 40 exatnines 
the IP pac kets to deteri^inc their type from the data portton of the packet as shown in 
> Figure 4A. The packets could be ia one of four categories: H.225, H.245, RTF and 
RTCP- T he steps of the raethod for H.225 packets are sho^vn in Figi^c 3A, while the 
proced.ue. for the vemaining packet types are shown in Figures 3B-3D, respectively. 

Once the type of the packet has been determined, both the packet itself i^ tl^ 
Monnati..o regardine the type of packet are both passed to management module 28, as 
,0 .hown ii) Figure 2. The packet is thCB passed to Ihc relevant component ^vithin 
management module 28, also as shown in Figure 2, for the recording process to be 
perfo^^cd. The recoxd.d packets are stored in storage module 30, as described in 
gjeatcr dijtail below with regard to Figures 3C and 3D. 

If .he packet has been detcimined to be an H.225 packet according to tbc header 
i5 of the packet (see Figure 4B). th= packet is passed to an H.225 call control module 78 
..dun n,anagemer,t module 28, a3 shown in Figvire 2. The steps of the management 
method ^ as follows, with reference lo figure 3A. In step 4A of Figure 3.A, the H.225 
packet H exaniired to see if it is a sen? packet, which is determined according to the 
structur.i of the data in the packet. This structure is specified in the H.225.0 
20 recomrr-endation. and includes at least the following types of information: 
protocoUdcntifier (the version of H-225.0 which is supported); 
ia45Address (specific ransport address on which H.245 signaling is to be 
established by the calliag cndpoinl or gatekeeper); 

sourceAddrcss (the H.323 JD's for the source); 
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sciircelnfo (contains an EndpoiatType to enable ihe part^- being caUed to 
deteiminf: whether the call includes a gateway or not); and 

d£stir,3TionAddrcss (this is the address to which the endpoint wants to be 
connecteti). 

5 Other types of data are also required, as specified in the H225.0 Kecommendation. 
This data structure enables H.225 call control module 78 to determine whetlier the 
packet is a setup packet. 

If iihis packet is a setup packet, then the first branch of the method is followed. 
TTie source port is taken from a source port field 74 of m H,225 header 72. and the 
10 desiinatioii port is taken fronn a desdnation port tield 76 (see Figure 4B). In step 5A, 
database 16 of Figure 1 is then examined to determine whether either of the 
corresponding terminals is defined as a recording tenninal; that is, whether 
commumcjlion sessions initiated by the IP address of this terminal should be 
monitored. If m.e, then in step 6 A, the terminal status is set as a start session request 
15 from die terminal corresponding to the source port. 

Altianarively, the packet is examined to see if it is a comiect packet in step 4B, 
which is dtrteiimned according to the structure of the data in the packet. This structure 
IS specified in the H. 225.0 reconimeadation, and includes at least the foUowing types of 
inforniatiorL: 

20 protocoildeniifter (the version of K.225 0 which is supported); 

h24.)Address (specific transport address on which H.245 signaling is to be 
established by the calling endpoint or gatekeeper); 

destliiationTufo (contains an EndpoiatType to enable the caller to detennine 
whether the call includes a gateway or not); and 
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cojiferenccID (contains a unique identifying number to identify the particular 
coniereiicii). 

If the packet is a connect packet, then the second branch of the method is 
followed. In step 5B, ihe flag uidicaticg the terminal status is exfunined to determine if 
5 the terminal status is set as a start session request In step 6B, tlie details of the call 
signal are saved in a call progress database 78 of storage medium 30 (see Figure 2). 
These detdls preferably include the source and destination I? addresses, the source and 
destination ports; the time at wliich tJie communication session was initiated, and any 
other rclevanl infonnation. In step 7B, the status of the ten-runal is set to '"vi'ait for the 

.is:; 

ip 10 logic channel 

if; Jf ihe packet has been determined to be an H.245 packet by second filtering 

y component 40. the packet is passed to an H.245 call control module 82 within 

III nianagemcnt module 28, as shown in Fi^e 2. Such H.245 packets are necessary for 

i3 H.245 signaling. H.245 signahng is established between two endpoints: an endpoint and 

1^ 1 5 a niulti-poi ni conuoller, or an endpoint and a Gatekeeper (see Figures 6 and 7 below for 

1 1; example^; <ind a description of such endpoints). Each endpoint is capable of calling and 

" of being eddied as part of a communication session. However, the system of the present 

invention cmly monitors, rather than initiating, such communication sessions. Thus, the 
system of the present invention ases the H.245 signahng to detemiine when the 
20 communic.ition session has started in order to effectively record the necessary data 
packets for the storage and later reconstruction of the session. 

Thii steps of tlie management method for R245 packets arc as follows, with 
reference to Figure 3D, hi step lA of Figure 3B, the H.245 packet is examined to 
rlctermine if it is an open logical channel request packet If it is, then in step 2A, the 
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terminal mm is examined to detemiine if the status is "wait for the iogiciH] channel". 
If 50. Iheii in step 3A the teiminal status is scl to "wait for acknowledgment". 

Alternatively, the H.245 packet Is examined to detennine if it is an open logical 
channel acknowledgment packet, as shown in step IB. If it is, then in step 2B, the 
5 teirainaJ status is examined to detennine if the status is *Vait for acknowledgment". If 
so, Uicii ,n step 3B the teiminal status is set to -Svait for terminal capabiUty". In step 
4B, the transport address of the "called" or destination terminal is saved. This transport 
address i:; taken from the destination port field 76 of header 72 (see Figure 4B). It 
''^""'•^ '"''^'^ ^'^^ «-225 a,id H.245 packets have identical header structures. 
0 10 Aho altei-natively. tiie H.245 packet is examined to determine if it is a tetminal 

P capability aet packet, as shoxvn in step IC. Tf it is, then in step 2C, the terminal 

'4 capability is saved in call progress database 80 (see Figu«e 2). In step 3C. tfie tenninal 

n status is set to "in call process'', sach lhat the communication session has been 

3 detcnnined to be opened and such that management module 28 can now receive RTP 

pi 

^ \5 data packets. 

3 '^^ P^'^^*^ ^5 determined to be a RTV packet by second filtering 

=^ oomponeni 40, the packet is passed to a RAS (registration, admissions and status) 

control module 84 within management module 28, as shown in Figure 2. Tie steps of 
management method for RTP packets are as follows, with reference to Figure 3C. in 
20 step 1 of Figure 3C, the terminal status is examined to see if it is call process". If so 
tiien in step 2. the RTP prickets are saved ui a RTP database 86 within storage medimu 
30 (see Figure 2). Figure 4C shows the structure of the RIP packet header, which can 
be used to identify the communication session ftom which the packet was taken. 
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Fin:Vily, if the packet has been determined to be a RTCP packet by second 
filtering component 40, the packet is passed to a RTCP control module 88 within 
management module 28, as sbovvn in Figure 2, The steps of the management method 
for RTCP packets are as follows, with reference to Pigure 3D, In step 1 of Figure 3D, 

5 the terminal status is examined to see if it is "in call procesu". If so then in step 2, the 
RTCP packets are saved in call progress database 80 within storage medium 30 (see 
Figure 2). Figure 4D shows the Structure of tlie RTCP packet header, which can be used 
to identify^ the communicaiion session from which the packet was taken. 

T]vx% Figures 3A-3D iHustrate the method of the present invention with regard 

10 to ihe filtering and storage of data packets which consiilatc the recorded 
communication session, as recorded by the system of Ihe present invention as shown in 
Figures 1 md 2. Of course, in addition to recording such communicatSon sessions, the 
sysiem of the present invention is also able to retrieve and to replay these 
communication sessions to the user. The stored communication session, composed of 

1 5 stored datia packets, can be retrieved and displayed by data vestoic unit 32 of Figure 2, 
in conjunvnion with audio unit 34 md video unit 36. The mediod of retrieving and 
replaying sessions of interest is shown in Figure 5, while certain other relevant portions 
of the sysiem of the present invention are shown in Figure 2. 

In step 1 of Figure 5, the user inputs the infomiation concerning the 

20 communication ^lession which is io be retrieved and replayed. This information 
preferably includes the termiaal number, or other designation information concerning at 
least ojie of the parties of the communication session of interest; the time at which the 
session started; and the time at which the session »aided- However, alternatively other 
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infonriatii^n could be included in place of This information, as long as suiricient 
informatii^n is pTovided for the communicatioxi session of interest to be identified. 

In step 2 of Figure 5, call progress database 80 (see Figujrc 2) is searched by data 
restore miit 32 in order to find the details of the conununication session(s) in the 
5 specijied ]:ime range. These details are then compared to the information entered by the 
user to loc ate st least one commwiication session of interest in the call range, 

lo step 3, RTP database S6 of storage medium 30 (see Figure 2) is searched, 
again by data restore unit 32, to find substantially all data packets from the at least one 
coimnunication session in the specified caJl raiige. Optionally and preferably, in iStep 4, 
io if the audio portion conimunicatioa session was recorded in stereo, than the data 
packets arc divided into different audio channels. 

In :;tcp 5, the data packets are restored by data restore \init 32 by an RTP (Real 
Time Protocol) soIUwe module 91 within data restore unit 32. RTP software module 
91 orders die data packets within each channel according to ttie time stamp of each 
15 packet. A3 shown ia Figure 4C, an RTP packet header 92 features several important 
fields: a tiracstamp field 94, a s>i:3Chronization source (SSRC) identifiers field 96 and a 
contributing source (CSRC) identifiers field 98. SSRC field 96 is used to determine the 
source of the RTP packets (die sender), which has a unique identifying address (the 
SSRC ideniifier). The CSRC identifier in CSRC field n is used in a conference with 
20 multiple parties, and indicates the SSRC identifier of all parties. Timestamp field 94 is 
u$ed by RTP software module 91 to determine tlie relative time at which the data in 
each packei should be displayed. 

For example, preferably the audio stream data of the audio speech of one person 
is synchronized to that person's lip n:\ovcments as shown in the video stream, a process 
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kiKJwn as 'lip syiichrooiration". Such syncbronization requires more than simply 

replaying aodio aixi video data at certain relative time points, since the audio arid video 
data packds Hiay not arrive at the same time, and may therefore have slightly different 
timesiainpi:. 

5 Oni;e the data packet has been coiTectly synchronized, the control of tlie display 

of tl^ audio data is th^n performed by aT. audio component 102 of data restore, unit 32 
according to one or more audio CODEC'S (see Figure 2). The coatiol of the display of 
the video data is then pertbnned by a video component 100 of data restore unit 32 
according.to one or more video CODEC'S (see Figure 2). 
10 Suitable CODEC^ s include, but are not Umited to, an audio codec using CClTf 

R,commo.,',dalion GJll (1988), Pulse Code Modulation (PCM) of voice Jreguenci,,; 
an audio codec using CCrrr Recomme.doTlon 0.722 (1988), 7 kHz audio-coding 
mthin 64 kbit/r, an audio codec using ITL'-T Recommcndaiion 0.723. 1 (1996). Speech 
coders: Dual rale speech coder for mukimedw communications trmsntltting at 5.3 
, 5 W 6.3 Khps; an audio codec asing CCITT Recommendation G. 728 (1992), Coding of 
speech ai 16 Kbp^^ unng Melay code excited linectr pndictiom an audio codec usiDg 
nUT R^^ommmdotion G.729 (1996), Codmg of speech at 8 Kbps- using conjugate, 
structure algebraic code-excited linear-prediciior, (CS-ACELP); a video codec using 
ITU-T Recommendation H.261 (1993), Video codec for audiovisual services ai 
20 p X 64 kbit/s; a video codec using ITU-T Recommendation H.263 (1996). Video coding 
for hw bit rate commmicauon; and substantiaUy any other similar coding standard. 

AS shoAvn i.i Figure 2, the audio data is displayed by audio unit 34. v/hich could 
include a loudspeaker, for example. T^ie video data is displayed by video unit 36. 
vvhich could include a display monitor screen, for example. Step 5 of Figure 5 is then 
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preferab ly i-epeated, sucli that substantially the entirety of the communication session is 
clisplaye<3. As shown in step 6, each data packet of the commuiikation session is 
examincj to sec if the call time is over. If che individual session has not completed, 
piefembly step 5 is repeated. Alternatively and preferably, if the call time is over, then 
5 call pro§:Tess database 80 is searched to see if otber communication sessions were 
recorded witliin the given time period, as shown in step 7. If there is at least one other 
such coramrjiication session, then preferably the method of Figure 5 is repeated, 
starting f rom step 2. 

According to prefened embodiments of the present invention, several 
10 configurations cf tlie computer logging system are possible, examples of which are 
shovvn in Figures 6 and 7. 

According to a first etnbodiment of the system of the present invention, shown 
in Figure 6, a typical basic configuration system 104 includes a single communication 
session management unit 13, substantially as shown in Figures 1 and 2, according to the 
15 present invention. Communication session management unit 13 manages 
communictation in a stand-alone intranet such as a LAN 106. LA\^ 106 is connected 
bcvdi to nonmiianication session management imit 13 and to a plurality of terminals 108, 
designated as "Tr\ and so forth, which follow the H.323 protocol. Each terminaJ 
108 is an endpeinl on LAN m which provides for real-time, two-way communications 
20 uith finother tenninal 108, a gateway 110, or a multipoint control unit (MCLO 112. This 
comraunication consists of control, indications, audio streams, video streams, and/br 
data. Termioal 108 is optionally only capable of providing such connnunication for 
audio only, audio and data, audio and video, or audio, data and video. As noted 
previously in the "Description of the Background Art" sectioti, die H.323 entity could 
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be a temninal which is capable of providing audio and/or video comTnunication as a 
'LAN lelr.phoije'', but could also be a stand-alone audio or video telephone. 

Gateway 110 (GW) is constnicted according to 11.323 and is an 
eudpoint on L AN 106 which provides for real-time, two-way communications ben\een 
5 tjerminals 108 on LAN 106 and other suitable terminals on a WAN (not shown), or lo 
another s ich Gateway (not shown). Other suitable terminals include diose complying 
with Recommendations H.310 (H.320 on B-TSDN), H.320 (ISDN), H.321 (ATM), 
H.322 (GQOS-L.AN). H.324 (GSTN), H.324M (MobileX and V.70 (DS VD). 

MCU 112 is a]i endpoint on LAN 106 which enables three or more terminals 
10 108 and giateways 1 10 to participate in a multipoint conference. 

Preferably, 3>'stem 104 also features a gatekeeper (GK) 114, which is an H,323 
eniit}- on LAN 106 which provides address translation and controls access to LAN 106 
for terminals 1(18, gateways 110 and MCUs 112. Gatekeeper 114 may also provide 
other services to tcnninals 108, gateways 110 and MCUs 112 such as bandwidth 
\5 m:anaecnLcnx and locating gateways 110. Prefeiably, gatekeeper 114 enables the IP 
address of Terminals 108 on LAN 106 to be determined, such that the correct IP address 
can be determined ''on the fly'\ 

In addition, LAN 106 may support non audio visual devices for regular T.120 
data applications such as electronic whiteboards, still image transfer, file exchange, 
20 database access, etc. 

In basic system 104, a single^ stand-alone communication session maaiagemeni 
unit 13 is used for monitoring, logging and retrieval of all audio and/or visual calls 
either between any two or more terminals 108 attached to LAN 106 or any call to 
which ore or more of these terminals 108 is a party. 
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However, for the preferred embodiment of the system of Hgure 6 which 
includes gaiekccpcr IM, as well as for the system of Figure 7, once the comxniinicatinn 
session has been opt:ned, preferably RAS conin^l tnoduie 84 also performs RAS 
sig^ialing betAveen the mimagement control module andMC 16 where necessary for the 
5 cortfiguraTion of the ifysLcni. Such signaling uses H.225.0 messages to perforai 
rt-gistrmion, admissions, bandwidth changes, status, and disengage procedures bet^^^een 
endpointa and gatekeepers. These messages are passed on a RAS Signaling Channel, 
which is independent from the Call Signaling Channel and the 11.245 Conti-ol Channel 
open logical channel procedures are not used to establish the RAS Signaling 
h) Channel. In LAN enviromncnis which contain a Gatekesper (a Zone), the RAS 
Signaling Channel is opened between tlie endpoint and the Gatekeeper. The RAS 
Signaling Channel is opened prior to the establishment of any other channels betv/ten 
H.323 endpoints. 

figure 7 shows a second embodiment of the system of tie present in^'ention as a 
J 5 zone configuration system 116. A zone .1 18 is the collection of all teiminals (Tx) IQ8, 
gate^vays (GW) 1 10, and muUipcint control iiniis (^4CUs) 112 managed by a single 
gatekeeper (GK) 114. Zone 118 includes at leasl one tenuinal 108, but docs not 
necessarily include one or more gateways 110 or MCUs 112. Zone 118 has only one 
gatekeeper 114 as shown. However, in the preferred embodiment shown, zone 118 is 
20 preferably independent of LAN topology and preferably includes multiple LAN 
segments 120 which are connected using muters (R) 122 as shown or other similar 
devices. 

Each mctutored LAN segment 120 has a local communication managemeni unit 
124 according to the present invention, of whicli two are shown. A central managernent 
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unit 126 according to the present invention controls all local communication 
„,ax,agemcnt units 124. In addition to centralized database and control s^es, central 
management tmtl 126 can he used for tt^e red-time monitonns and off-line restoration 
of audio a.Ki;or video conununication sessions fron. a single point. Central maaagmcnt 
5 urut 126 is opMy and pi^ferably cither u dedicated unit simil^^ in structure to local 
co™-cation management units 124 but without the borage capabiUt,^ or central 
nunagement uutt 126 is aherr.atively and preferably integrated with local 
communication tn^agetncnt units 124 to provide the functionality of both local 
conrmuaication management unit 124 and central management unit 126 in a single 
,0 statioa. Local conununication management tmits 124 are preferably either 
„nucat.cn session management unit, 13 substantially as described in Figures 1 
.md 2., or alternatively .md preferably are simpler units which lack the capability to 
retrieve ajid display a communication session locally. 

In slill ai^other preferred embodiment of the present Invention (not shown), 
.5 multi-user operation based on Client/Sewer architecture is preferably supported for 
basic system 104 and zone system U6. An unlimited number of "Client" stations may 
be comiected anywh^e on tlte LAN, providing «se« with management and 
monitoring/retrieval capabilities detertnined by the authorization level of each specific 



user. 

20 



Yer another preferred embodiment of ihc present invention, illustrated in Figure 
addresses the challenges of an Litemet Protocol (IP) dislributed switching 

environment. 

Recording systems experience the following challenges when interfaced with an 
IP environment: 
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Because theie is no central switching matrix, voice streams between any 
extension A and B can be routed via ihe WAN without providing 
u rneans tu capture the calls at the she where the recording 
systems arc located, 

5 Because the IP network consists of switch boxes, routers and bridges, 

the network topology can have a negative influence on the 
recording. 

Few multimedia IP protocol suites include encryption. In particular, the 
H323 protocol suite lacks encryption. In order for the recording 

in 

'0 10 system to de-encrypt the signal, the j^ording system needs lo act 

\J\ 

m as a "legar ptuiy with the recorded call. The only way to 

become a "legal" party with the recorded call is to turn the call 

i n 

I fj into a conl'etcncc call in which the recording system is one 

: ^ member of the conference. 

f2 15 Multimedia IP protocols define several types of audio and video 

:i CODECS {G.7n, G-722, G.728, GJ22, 0.729, 11.261 and 

Q 11.265). Thus, during recording playback operation the recording 

system should have the capability of changing iiom one 
CODECS to aiiother per the endpoint capabilit>', if the voice or 
20 the video was recorded and stored using a different CODECS. 

System 104 of Figujre 6 is intended for tise m a standard H-323 environmwat. 
Terminals 108 conduct telephone conversations among tliemselves, or aUemadvoly 
with POTS telephones via gateway 110. Tn order to make These calls, terminal 108 
communicate ^Yith gatekeeper 114 in order to find the destination tenninal or gateway 
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on LAN using dn? RAS protocol to perform call scmp under the H.225 protocol and to 
negotiate the RTP stream characteristics under the H.245 protocol. Note tliat these 
protocols all belong to the H.323 protocgl suite. The communication with gmeket^pcT 
114, under the R.\S, H.225 and H.245 protocols, h Hie signaling part of the call and is 

5 used to eiitabli^ the RTP or RTCP streams of the call which are used to carry the actual 
voice or video data. MCV 112 provides die ability to perform conferencing among 
three or more parties. All of the above communications are perfonTLed over T.AN 106. 

Communication session management unit 13 is connected un LAN 106 in such 
a way that communication session management unit 13 is able to sniff all ihc packets of 

1 0 a conversation, both signaling packets and RTF or RTCP packets. Prior art connection 
methods include: 

1. using a hub, in which case all packets are passed to all porU> in 
the hub; and 

2. monitoring strategic pons of a switched hub by other ports on the 
15 swiichedhub. 

Likely sLraiegic ports under the second alternative are the ports of the switclied hub to 
which one or more gateways 110 are connected in wiiich case all outgoing calls can be 
recorded. In tliis example, gateway 110 is connected to the monitored port of the 
switching hub and coiiimuxiicalion session management unit 13 is connected to the 
20 rnonitorini^ port of the switching hub. 

Commmiication session management unit 13 sniffs the RTP and R TCP packets 
of the convcrsatiou ajid extracts the voice or video data from these packets. In order to 
associate tliese dam with a telephone extension number, or with the name of the person 
at the extension, the H;323 signaliag must be analyzed. This soluiiun does not work in 
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Voice Over IP systems in which tlie signaling protocolj; are not uithin the H.323 
protocol suite. Such signaling protocols include SIP, MGCP and Cisco'-s proprietary 
Skinny protocol. 

A third embodiment 150 of ihs $ysteni of tlie present invenuon, ttiat does nul 
5 depend on Qie signaling prc^tocol, is illustrated in Figure 8, In system ISO, the voice or 
video data are recorded, as in system 104 of Figure 6, by haAnng communication sesiijion 
TTianagement unit 13 sniti'the R iV suidRTCP packets. The innovation of system 150 is 
the addition of a link 160 between communication session manageruent unit 13 and 
3 gatckeei>er 114. Specifically, link 160 connects management module 28 of 

P 10 commuiucation session management unit 13 to gatekeeper 114. Link 160 provides CTl 

p (compuiei telephone integration) data or CDR (edl data records) data to 

Jl communication session m^anagement unit 13. These data replace the data wliich are 

rctrie\^ed by analyzing the H.323 protocols in sviiiem 104 of Figure 6. These data 
Q include caller's IP address, and other identifying information, such as extension 

7i 15 number, :;aller's name, or any other information that arrives via lirik 160. Optionally, 

i the caller's IP address may be inferred from the other identifying information. These 

data are used by communication session management unit 13 to associate calls with 
extension numbers, cailerii' names or any other information that arrives via link 16U. 
Link 160 is a logical link that may be implemented in several ways, including: 
20 1. On the same LAN tliat is u^d for Voice Over IP calls. In this 

manner, no additional hardware is needed on communication 
session jnanageinent unit 13. 
2. On a separate LAN from the LAN that is used for Voice Over IP 
calls. Under this alternative, communication session 
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management unit 13 includes an addilionsil network adapter, 
siiTiiJar to NIC 16, that is used specifically for link 1 60- 
3. On a serial connection using one of the serial ports of 
coinnnmication session management unit 13. 
5 Because link 160 is a logical link. Figure 8 serves to illustraie all three of these 
impicmentatioas. 

System 150 of Figui^c 8 has the following advaniageii: 

1 . Thefv^ is no dependence on the t>'pc of signaling iLsed in the Voice Over 
IP system. System 150 works with all signaling types. 
10 2. Link 160 may transfer more information than can be retrieved from tlie 

H.323 bsignaling proiocols. This infotmation may include, for example, applicatioTi- 
specilic infonnation such as insurance policy number in the case of system 130 being a 
component of an insurance compsny^s call center. 

5. Because fewer messages arrive at communication session management 
15 unit 13. system 150 reduces the burden on the CPU of communication $e.cision 
management unit 13» resulting in an increase in die number of cliaiuiels that can be 
recorded simuhaneously. 

System 150 of Figure 8 may be reduced to practice using the tbllowing 
commercially available components: 
20 Gaiekeeper 114: Call Manager 3.0™ by Cisco Systems, Inc., San Jose OA 

Link 160: A JTAPF^^ connection of tlie Call Manager 3,0™ 
Teiminals 108: VIP 30^" or SP VZ-^'^"^, both by Cisco Systems, Inc.. San Jose 

CA 
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Gateway 110: Cntfllyst 364f)™, by Cisco Systems, Inc., San 3o^ CA 
MCU 112: Canifcjrence Plug-kx on the Call Manger 3,0™ 
Commiinication session management unit 13: Nicelog™, by Nice Systems Ltd.^ 
Ra*anana, Israel 

LAN 106: Switch Hub Catalyst 2924'^^, by Cisco Systems, Inc., San Jose CA 
It will be appreciated that ihc above descriptions are intended only to serv'e as 

examples, and that tuaiiy other embodiments arc possible witliiri the spirit and the scope 

of the present invention. 



